Many application protocols, like SIP (Session Initiation Protocol) or RTSP (Real-Time Streaming Protocol), used for multimedia communications are text-based and engineered for links having wide bandwidth. As a result, their messages have not been optimized in terms of size. For example, typical SIP messages range from a few hundred bytes up to two thousand bytes or more. With the planned usage of these protocols in wireless handsets as part of 2.5 G and 3 G cellular networks, the large message size is problematic. With low-rate IP connectivity the transmission delays are significant. Taking into account retransmissions and the multiplicity of messages that are required in some flows, at least call setup and feature invocation are adversely affected.
To eliminate this problem, Signaling Compression (SigComp) architecture has been defined for robust, lossless compression of application messages. In terms of the OSI model, SigComp architecture can be interpreted as an enhancement to transport layer. Thus, SigComp provides the higher layer applications for both transmission and compression of the messages. Due to its usefulness in mobile communication, 3rd Generation Partnership Project (3GPP) has recommended the use of SigComp at least for compressing SIP messages. Therefore, the future 3G mobile terminals must support SigComp.
The transmitting side of the SigComp architecture comprises the entities of a compressor dispatcher, one or more compressors and a state handler. The compressor dispatcher serves as the interface from the application. The application supplies the compressor dispatcher with an application message and a compartment identifier (i.e an identifier that is used for application-specific grouping of messages). The compressor dispatcher invokes a particular compressor, which returns a SigComp message to be forwarded to the remote endpoint. State handler stores and retrieves state information that is stored between SigComp messages in order to avoid the need to upload the data on a per-message basis.
The receiving side of the SigComp architecture comprises the entities of a decompressor dispatcher, an Universal Decompressor Virtual Machine (UDVM) and a state handler. The decompressor dispatcher serves as the interface towards the application. The decompressor dispatcher receives a SigComp message from the transport layer and invokes an instance of the UDVM, which decompresses the SigComp messages. The decompressor dispatcher then forwards the resulting decompressed message to the application, which may return a compartment identifier if it wishes to allow state to be saved for the message. During the decompression process the UDVM may invoke the state handler to access existing state or create new state.
The SigComp messages are transmitted as data packet flow on the transport layer along with other application messages, e.g. uncompressed SIP and RTSP messages. The SigComp messages are identified with own five-bit delimiters, i.e. they start with 11111 bits and end with 0xFFFF bits. Thus, the transport layer data stream is directed to the decompressor dispatcher, which must be arranged to identify the SigComp messages for decompression and to pass the non-SigComp messages to a particular application client, like SIP stack or RTSP.
One of the disadvantages associated with the above arrangement is that the decompressor dispatcher must be aware of all application clients and the delimiters they use. Thus, every time when a new client is introduced, the decompressor dispatcher logic must be updated. A further major problem is involved with the binary content of the application messages. The delimiters of SigComp messages may appear also in application messages, e.g. 11111 bit pattern may be found in a SIP message. This may lead to misinterpretations of delimiters in the decompressor dispatcher and result in malfunction of the dispatcher.